\section{Mechanical Design}

\subsection{Reaction Wheel System Development} % (fold)
\label{ssub:Reaction Wheel Control System Development}

\begin{figure}[ht]
	\centering
	\includegraphics[width=0.8\textwidth]{control/reactionwheel.JPG}
	\caption{A detail from the prototype design showing the reaction wheel and DC motor. Electronics thermal box made translucent and electronics removed for clarity}
	\label{fig:hobreaction}
\end{figure}

The yaw attitude of the gondola must be controlled by the reactive torque of a flywheel. A reaction wheel mechanism has been designed with a Moment of Inertia of and a mass of %TODO
The fly wheel is driven by a 24V DC torque motor with optical encoder feedback \cite{dcmotor}. The peak torque of this motor is nominally 9Ncm. From previos flights, the twisting torque by the suspension rope has been estimated to be about two orders of magnitude lower than the torque exerted by the DC motor. The motors encoder feedback allows the motor to be biased to a continuous angular velocity to avoid static friction at the null rotation speed. A second smaller motor attached to the suspension line is commanded to exert a torque as a proportion of the flywheel's angular velocity to suppress a monotonic increase in flywheel angular velocity from small continuous disturbances, like vortices being shed from the balloon.
% subsubsection Reaction Wheel Control System Development (end)

\begin{figure}[ht]
	\centering
	\includegraphics[width=\textwidth]{control/servoblk.pdf}
	\caption{Block diagram of yaw servo control system}
	\label{fig:servoblk}
\end{figure}

The servo system block diagram designed to stabilise in azimuth is presented in Figure \ref{fig:servoblk}.
The yaw direction of the gondola is denoted by $\theta$, while $\theta_0$ indicates the reference value and $\theta_e$ indicated the error signal. $\theta_e$ is amplified by a servo gain $G_{RW}(s)$ and fed to the flywheel motor drive circuit which has a torque sensor of $K_T$. The suspension rope exerts a disturbance twisting torque $-I_0 \omega_{0}^{2}$. The rotation speed $\dot\psi$ of the reaction wheel is fed to the suspension-twist motor (whose control circuit gain is $G_{ST}(s)$ and whose speed sensor is $K_v$) so as to try and keep the reaction wheel speed at its biased nominal. $I_0$ is the moment of inertia of the gondola, $I_{RW}$ is the moment of inertia of the reaction wheel. $\omega_0$ is the angular rotation of the gondola and $S_A$ is the azimuth sensor. $\theta_1$ is the twisting angle of the suspension rope.

The equation of motion of the gondola is described by

\begin{equation}
	\ddot\theta = -J\ddot\psi - \omega_0^2(\theta-\theta_1)
	\label{rweom}
\end{equation}

where we define $J$ as the ratio if the moment of inertia of the reaction wheel to the moment of inertia of the gondola. %TODO diagram 
The rotation of the wheel is described by,

\begin{equation}
	\ddot\psi = a\dot\theta + b\theta
\end{equation}

where $a$ and $b$ are control constants to be determined. For the suspension-twist motor we can define the rotational velocity as

\begin{equation}
	\dot\theta_1 = -A\ddot\psi - B\dot\psi
\end{equation}

where $A$ and $B$ are also constants to be determined for the control system. We can equivalently write this as

\begin{equation}
	\dot\theta_1 = -C\theta - B\dot\psi
\end{equation}

We can now check the stability of the system. From the equations above we can state that:

\begin{equation}
	\ddddot\theta + a\dddot\theta + (Jb + \omega_0^2 + \omega_0^2Aa)\ddot\theta + \omega_0^2(Ab + Ba)\dot\theta + \omega_0^2Bb\theta = 0
	\label{bigeq}
\end{equation}

The Laplace transform of Equation (\ref{bigeq}) is a 4th-order polynomial, and so we can check its stability with the Routh-Hurwitz stability criterion as defined in \cite{rhsc}. Applying the criterion for stability we must satisfy the following inequalities:

\begin{equation}
	Ja>0
\end{equation}

\begin{equation}
  \frac{J^2}{\omega_0^2}ab + Ja + JAa^2 - Ab - Ba > 0
\end{equation}

\begin{equation}
  \frac{J^2}{\omega_0^2}Aab + JAab + JA^2a^2b + JABa^3 + A^2b^2 - 2ABab - B^2a^2 > 0
\end{equation}

\begin{equation}
	Bb\omega_0^2 > 0
	\label{rh4}
\end{equation}

These inequalities demand that $a > 0$, a positive damping term. We set $B$ and $b$ to be $> 0$ to be consistent with (\ref{rh4}).

\subsection{Gondola Design} % (fold)
\label{sub:Gondola Design}

The gondola provides the is the structure upon which the stabilisation systems are mounted. It must be stiff and light in the face of  

\begin{figure}[!ht]
	\centering
	\includegraphics[width=\textwidth]{control/gondola.JPG}
	\caption{A simplified view of the prototype gondola. The pitch cradle has been has been removed for clarity, but rotates between the two bearing channels shown.}
	\label{fig:hobgon}
\end{figure}

blah

% subsection Gondola Design (end)

\newpage

\section{Software}

The flight computer firmware was co-developed by the author and Fergus Noble. The LPC2368 is programmed through a JTAG interface using an open source toolchain based on a GCC compiler.

A pre-emptive multitasking kernel was selected to run as a real-time operating system, which significantly aided development and testing of the flight computer. The kernel has a compiled size of about 25kB which comfortably fits into the 512kB of Flash memory on the LPC2368. Tasks are then written for the kernel and run as processes, and assigned priority based on their importance. This allows guaranteed running of time-critical processes such as the control loop, and interrupts can be handled by the kernel from internal and external sources. Basic drivers for the peripherals were written and then more complex and capable flight logic processes were written on top. In total approximately 5000 lines of C code were written and tested for the basic operation of the flight computer.

\subsection{Software structure} % (fold)
\label{sub:Software structure}


The overall flight control software consists of several components:
\begin{itemize}
  \item \textbf{Flight Logic Sequencer}: This determines the region of the flight profile that the craft is in, and engages sub tasks as appropriate. It uses the GPS to ascertain whether or not the payload is ascending, descending, or floating. It is written as a state machine and analysis was performed to minimise that chance of getting stuck in a dead state should an error occur. Throughout this mode the telecommand subsystem is functioning so that the automatic flight sequencing can be overridden if necessary.
  \item \textbf{State Estimation and Control Law}: The flight logic sequencer initiates this state once a float has been detected or else it has been externally commanded. In this case the Kalman Filter is initialised and the control law and active stabilisation is begun. The pointing vector is determined from a pre-programmed look-up table which is programmed according to mission requirements. Various alarm states exist which can be telemetered down, such as control system saturation (specifically reaction wheel momentum saturation), low voltage alarms and so on. The control loop runs at 50Hz and is triggered by a timer interrupt on the microcontroller. All data computed at each stage of the control law (raw inertial readings, state estimates and control commands) are logged to the SD card.
  \item \textbf{Low level driver functions}: These occur beneath the real time operating system, and they allow the high level operating system tasks to access the processor's on-board peripherals and consequently the sensors, actuators and so on. Drivers were written from scratch for all peripherals, with the exception of the use of an open-source implementation of the FAT32 filesystem for use with the SD card \cite{fatfs}. 
\end{itemize}
% subsection Software structure (end)
\newpage
\section{Flight Testing}

Testing the flight computer on a real balloon flight is an important step to validate the large number of engineering decisions that have been made in its design. It must show that it is capable of withstanding the thermal environment, that the flight logic works as expected, and that the telemetry and telecommand systems function to specification.

To that end the flight computer underwent two test flights. The first was carried out on 9th December 2009 and the second and the second on 26th February 2010. These tests demonstrated:

\begin{itemize}
	\item Flight computer operation to 32km and -40\textdegree C
  \item Two-way simplex communications with the flight computer
  \item Operation of the inertial measurement unit after cut-away command has been sent to log initial tumbling
  \item Full SD card logging of pre-and post-processed inertial data
\end{itemize}

The SD card logged the position updates given by the GPS unit and these can be plotted in three dimensions using Google Earth software. Figure \ref{fig:testflight} shows the flight path of the test flight. The colour corresponds to the velocity of the vehicle, the fastest point being immediately after a cut-away is initiated from the balloon where terminal velocity is higher due to the thinner atmosphere.

\begin{wrapfigure}{r}{0.4\textwidth}
	\vspace{-1cm}number
	\centering
	\includegraphics[width=0.45\textwidth]{control/badger2flight.png}
	\caption{The Flight Computer Test Flight Path}
	\label{fig:testflight}
\end{wrapfigure}

\subsubsection{Landing Prediction} % (fold)
\label{ssub:Landing Prediction}

% subsubsection Landing Prediction (end)

This test flight also provided an opportunity to test the new dynamic flight path prediction software written by several members of CUSF. This software integrates the balloon's ascent and descent profile through a weather forecast model to generate a flight path. The author's specific contribution is a dynamic ballistic co-efficient estimation module that uses telemetry immediately after cut-away, and during descent, to update the \emph{priori} estimate of the ballistic coefficient, so a better estimate of the landing spot can be produced. This is very important from the point of view of safety as it allows flights to be planned to avoid built-up areas with a reasonable confidence, and specifically allows the cut-down command to be sent in-flight when the predicted landing spot is favourable. 

\begin{figure}[ht]
	\centering
	\includegraphics[height=8cm]{control/nova16descent.jpg}
	\caption{The Flight Computer test payload in the final seconds of descent}
	\label{fig:b2down}
\end{figure}

Figure \ref{fig:b2down}, taken by the author during the test flight, validates the performance of the landing predictor because it shows that the recovery team where able to drive to the predicted landing spot ahead of time, some 80km away from the launch site, and be waiting within 200m of the actual landing spot in order to take the photograph. In combination with East Anglia's very flow population density, it is reasoned that pre-flight prediction can make the eventual flight of the stabilising prototype is low risk as possible.
